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1 . Real Party In Interest. 

The real party in interest is Extended Systems, Inc, a corporation established 
under the laws of the State of Delaware and having a principal place of business at 
5777 North Meeker Avenue Boise, Idaho 83713. 
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2. Related Appeals And Interferences. 

There are no other appeals or interferences known to Appellants, Appellants' 
legal representative or the Assignee which will affect or be directly affected by or 
have a bearing on the Board's decision in the pending appeal. 

3. Status Of Claims. 

Claims 1-7, 10-12, 15, 17-23, 26-28, 31 and 47-48 are pending but stand 
rejected. Claims 8, 9, 13, 14, 16, 24, 25, 29, 30, and 32-46 were previously 
cancelled. The rejections of all pending claims are appealed. 

4. Status Of Amendments. 

No amendments have been filed after the final action was entered. All previous 
amendments have been entered. 

5. Summary Of Claimed Subject Matter. 

Claim 1 is directed to a coordinated push synchronization method. That 
method includes detecting changes to a local application data store. See, e.g., 
Specification, paragraph [0045] and Fig. 10. A record affected by a detected change 
is identified. The identified record is pushed to a remote application data store. See, 
e.g., Specification, paragraph [0045] and Fig. 10. It is ascertained whether the 
pushed record, in its current form as affected by the detected change, has already 
been replicated or deleted in the remote application data store in order to determine 
whether the remote application data store will be updated with the pushed record. 
See, e.g., Specification, paragraph [0045] and Fig. 10. If the pushed record has not 
already been replicated in its current form as affected by the detected change, the 
remote application data store is updated with the pushed record, and the pushed 
record is identified in the remote application data store as having been pushed from 
the local application data store to the remote application data store. See, e.g., 
Specification, paragraph [0045] and Fig. 10. If the pushed record has already been 
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replicated in its current form as affected by the detected change, the pushed record 
is ignored. See, e.g., Specification, paragraph [0045] and Fig. 10. 

Claim 5 is directed to a coordinated user-initiated synchronization method. 
The method includes detecting changes to a local application data store and 
identifying a record affected by a detected change. See, e.g., Specification, 
paragraphs [0046]-[0048] and Fig. 11. It is ascertained whether the identified record, 
in its current form as affected by the detected change, was pushed to the local 
application data store from a remote application data store. I See, e.g., 
Specification, paragraphs [0046]-[0048] and Fig. 11. f the identified record, in its 
current form as affected by the detected change, was not pushed, the remote 
application data store is synchronized with the local application data store. See, 
e.g., Specification, paragraphs [0046]-[0048] and Fig. 11. 

Claim 10 is directed to a coordinated push and user-initiated synchronization 
method. The method includes detecting changes to a local application data store 
and identifying a first record in the local application data store affected by a detected 
change. See, e.g., Specification, paragraph [0045] and Fig. 10. The first record is 
pushed to a remote application data store. See, e.g., Specification, paragraph 
[0045] and Fig. 10. It is ascertained whether the pushed record, in its current form 
as affected by the detected change, has already been replicated in or deleted from 
the remote application data store. See, e.g., Specification, paragraph [0045] and 
Fig. 10. If not, the remote application data store us updated with the pushed record. 
See, e.g., Specification, paragraph [0045] and Fig. 10. Changes to the remote 
application data store are detected. See, e.g., Specification, paragraphs [0046]- 
[0048] and Fig. 1 1 . A second record in the remote application data store affected by 
a detected change is identified. See, e.g., Specification, paragraphs [0046]-[0048] 
and Fig. 11. It is ascertained whether the second record, in its current form as 
affected by the detected change, has already been pushed into the remote 
application data store in order to determine whether the remote application data 
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store will be updated with the pushed record. See, e.g., Specification, paragraphs 
[0046]-[0048] and Fig. 1 1 . If the second record, in its current form as affected by the 
detected change, has not already been pushed, the remote application data store is 
synchronized with the local application data store. Otherwise, the pushed record is 
ignored. See, e.g., Specification, paragraphs [0046]-[0048] and Fig. 11. 

Claim 17 is directed to a coordinated push synchronization computer program 
product comprising a computer useable medium having computer readable 
instructions thereon. Included are instructions for detecting changes to a local 
application data store, identifying a record affected by a detected change, and 
pushing the identified record to a remote application data store. See, e.g., 
Specification, paragraph [0045] and Fig. 10. Also included are instructions for 
ascertaining whether the pushed record, in its current form as affected by the 
detected change, has already been replicated or deleted in the remote application 
data store in order to determine whether the remote application data store will be 
updated with the pushed record. See, e.g., Specification, paragraph [0045] and Fig. 
10. Also included are instructions for updating the remote application data store with 
the pushed record and identifying the pushed record in the remote application data 
store as having been pushed from the local application data store to the remote 
application data store if it is ascertained that the pushed record, in its current form as 
affected by the detected change, has not already been replicated or deleted in the 
remote application data store. See, e.g., Specification, paragraph [0045] and Fig. 
10. The medium includes instructions for ignoring the pushed record is it is 
ascertained that the pushed record, in its current form as affected by the detected 
change, has already been replicated or deleted in the remote application data store. 
See, e.g., Specification, paragraph [0045] and Fig. 10. 

Claim 21 is directed to a coordinated user-initiated synchronization computer 
program product comprising a computer useable medium having computer readable 
instructions thereon. Included are instructions for detecting changes to a local 
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application data store and identifying a record affected by a detected change. See, 
e.g., Specification, paragraphs [0046]-[0048] and Fig. 11. Also included are 
instructions for ascertaining whether the identified record, in its current form as 
affected by the detected change, was pushed to the local application data store from 
a remote application data store. See, e.g., Specification, paragraphs [0046]-[0048] 
and Fig. 1 1 . The medium includes instructions for synchronizing the remote 
application data store with the local application data store if it is ascertained that the 
identified record, in its current form as affected by the detected change, was not 
pushed to the local application data store from a remote application data store. See, 
e.g., Specification, paragraphs [0046]-[0048] and Fig. 11. 

Claim 26 is directed to coordinated push and user-initiated synchronization 
computer program product comprising a computer useable medium having computer 
readable instructions thereon. Included are instructions for detecting changes to a 
local application data store, identifying a first record in the local application data store 
affected by a detected change, and pushing the first record to a remote application 
data store. See, e.g., Specification, paragraph [0045] and Fig. 10. Also included are 
instructions for ascertaining whether the pushed record, in its current form as 
affected by the detected change, has already been replicated in or deleted the 
remote application data store and, if not, updating the remote application data store 
with the pushed record. See, e.g., Specification, paragraph [0045] and Fig. 10. The 
medium includes instructions for detecting changes to the remote application data 
store and identifying a second record in the remote application data store affected by 
a detected change. See, e.g., Specification, paragraphs [0046]-[0048] and Fig. 11. 
The medium also includes instructions for ascertaining whether the second record, in 
its current form as affected by the detected change, has already been pushed into 
the remote application data store and, if not, synchronizing the remote application 
data store with the local application data store. See, e.g., Specification, paragraphs 
[0046]-[0048] and Fig. 1 1 . The medium includes instructions for ignoring the pushed 
record when it is ascertained that the second record, in its current form as affected 
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by the detected change, has already been pushed into the remote application data 
store. See, e.g., Specification, paragraphs [0046]-[0048] and Fig. 11. 

6. Grounds For Rejection To Be Reviewed. 

A. Claims 1-7, 10-12, 15, 17-23, 26-28, 31 and 47-48 stand rejected 
under 35 USC §1 03(a) as being unpatentable over Brown (US Pub. No. 
2002/0174180) in view of Ferrat (US Pub. No. 2005/0055382). 

7. Argument. 

A. Ground For Rejection A: Claims 1-7, 10-12, 15, 17-23, 26-28, 31 and 
47-48 stand rejected under 35 USC §1 03(a) as being unpatentable 
over Brown (US Pub. No. 2002/0174180) in view of Ferrat (US Pub. 
No. 2005/0055382). 

Claim 1 is directed to a coordinated push synchronization method and 
includes the following combination of elements. 

a) detecting changes to a local application data store; 

b) identifying a record affected by a detected change; 

c) pushing the identified record to a remote application data store; 

d) ascertaining whether the pushed record, in its current form as affected 
by the detected change, has already been replicated or deleted in the 
remote application data store in order to determine whether the remote 
application data store will be updated with the pushed record; 

e) if not, updating the remote application data store with the pushed 
record and identifying the pushed record in the remote application data 
store as having been pushed from the local application data store to 
the remote application data store, otherwise ignoring the pushed 
record. 
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With respect to fourth element listed above, the Examiner asserts that Brown, 
paragraphs [0071] and [0080]-[0083], teaches "ascertaining whether the [pushed] 
record, in its current form as affected by the detected change, has already been 
replicated or deleted in the remote application data store in order to determine 
whether the remote application data store will be updated with the pushed record; if 
not, updating the remote application data store with the pushed record." The 
Examiner Admits that Brown teaches that this act is performed before any data is 
pushed. The Examiner also indirectly admits that Brown fails to teach ignoring a 
pushed record if it is ascertained that the pushed record, in its current form as 
affected by the detected change, has already been replicated or deleted in the 
remote application data store. 

To remedy Brown's deficiency, the Examiner mistakenly relies on Ferrat. The 
Examiner never asserts that Ferrat teaches ignoring a pushed record if it is 
ascertained that the pushed record, in its current form as affected by the detected 
change, has already been replicated or deleted in the remote application data store. 
The Examiner mistakenly asserts that Ferrat, paragraphs [0089]-[0091] teaches that 
a "record is pushed to the remote application data store prior to determining whether 
the record should be updated." 

Claim 1 recites updating a record store and not updating a record. As such, 
the Examiner's continued assertion that Ferrat teaches pushing a record prior to 
updating the record is irrelevant. Assuming this to be a typographical error on the 
part of the Examiner, the cited paragraphs make no mention or suggestion of a 
record that is pushed to the remote application data store prior to determining 
whether the record store should be updated with the pushed record as recited in 
Claim 1. The cited paragraphs are reproduced as follows: 

[0088] 3.3 Push and Pull Mechanism 

[0089] One of the requirements that we would like to satisfy is the 
ability to do both "push" and "pull" in a single UniSync engine. For 
example, the ability to do a "push" for a spoke to move all the changes 
to the hub server and eventually resolve conflicts, and then do a "pull" 
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to synchronize the hub server and the spoke database. These 
operations "push" and "pull" may be optional. 



[0090] The "push" and "pull" can be applied for all the commands that 
are described previously. UniSync engine provides the 3 basic 
commands snapshot, pointUpdate and continuousUpdate. They can 
"push" or "pull" depending of the requirement. 

[0091] These commands can be called directly from UniSync API. 
UniSync engine will support both "push" commands and "pull" 
commands at the same time. The user/application will decide to "push" 
or to "pull" and snapshot table for example depending on which site the 
command is executed. The outcome should be exactly the same for 
the UniSync engine. 



Ferrat, paragraphs [0088]-[0091]. 



The cited passage discusses a synchronization environment with central hub 
server with several spoke clients. A spoke client can push changes to the hub 
server. The hub server resolves conflicts, if any. The spoke can then pull changes 
The conflicts resolved by the hub server relate to related changes received from 
other spoke clients. See, e.g., Ferrat, paragraph [0082]. Ferrat makes no mention 
or suggestion that the hub server ascertains whether a changed record that has 
been pushed to the hub server has already been replicated or deleted in a data store 
of the hub server prior to updating that data store with that pushed record. 
Furthermore, Ferrat mentions nothing of ignoring the pushed record if it is 
ascertained that the hub server's record store has already been updated with the 
pushed record. 



With respect to fifth element of Claim 1 listed above, the Examiner asserts 

that Brown teaches "identifying the [pushed] record in the remote application data 

store as a pushed record (paragraph 0066) and identifying the [pushed] record in the 

remote application data store as having been pushed from the local application data 

store to the remote application data store, otherwise ignoring the [pushed] record 

(paragraph 0071)." 

Brown, paragraph [0066], is reproduced as follows: 
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[0066] Metadata 330 shows the metadata for file 320 as stored within 
CSFS 335, part of client SA 337. (Although metadata are not shown for 
the other files and folders within folder 302, a person skilled in the art 
will recognize that such metadata exist.) In metadata 330, file 320 is 
shown as having a name (which is typically not encrypted, although the 
name can be encrypted in an alternative embodiment of the invention), 
a CID of 0x62, a SID of 0x2A, a FSI of 35, the change time of the file, 
and the flags used in the synchronization process (such as 
identifying metadata items that need to be pushed to the server). 
Note that metadata 330 is not shown to store the data of file 320, which 
is stored in the native operating system of computer 130 within the 
folder structure, as expected. 



Brown, paragraph [0066] (emphasis added). Brown's paragraph 66 mentions 
nothing of identifying a record in the remote application data store as a pushed 
record. It simply discusses a flag that identifies metadata (not a record) that needs 
to be and has not yet been pushed to a server. 

Brown, paragraph [0071], is reproduced as follows: 



[0071] The client polls the server for changes by other clients by 
passing its current CSI to the server in a sync polling call. If the CSI 
matches the server account's SSI value, then the client is up to date 
with the server. Otherwise the client SA requests server 
synchronization data (SSD). The SSD contains the following data: 



Brown, paragraph [0071]. Brown's paragraph 71 mentions nothing of identifying a 
record in the remote application data store as having been pushed from the local 
application data store to the remote application data store 



Consequently, the combination of Brown and Ferrat fail to teach or suggest a 
method that includes: 



a) ascertaining whether the pushed record, in its current form as affected 
by the detected change, has already been replicated or deleted in the 
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remote application data store in order to determine whether the remote 
application data store will be updated with the pushed record; and 
b) if not, updating the remote application data store with the pushed 
record and identifying the pushed record in the remote application data 
store as having been pushed from the local application data store to 
the remote application data store, otherwise ignoring the pushed 
record. 

For at least these reasons, Claim 1 is patentable over Brown and Ferrat. 
Claims 2-4 and 47 are thus also felt to distinguish over those references based on 
their dependency from Claim 1 . 

Claim 5 is directed to a coordinated user-initiated synchronization method 
and includes the following combination of elements: 

1 . detecting changes to a local application data store; 

2. identifying a record affected by a detected change; 

3. ascertaining whether the identified record, in its current form as 
affected by the detected change, was pushed to the local application 
data store from a remote application data store; and 

4. if not, synchronizing the remote application data store with the local 
application data store. 

With respect to the third element listed above, the Examiner admits that 
Brown fails to teach or suggest "ascertaining whether the identified record, in its 
current form as affected by the detected change, was pushed to the local application 
data store; and if not, synchronizing the remote application data store with the local 
application data store." ONCE AGAIN it is noted that the Examiner is 
mischaracterizing that which Claim 5 recites - specifically - "ascertaining whether 
the identified record, in its current form as affected by the detected change, was 
pushed to the local application data store from a remote application data store " 
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(emphasis added). The Examiner's discussion of Claim 5 ignores this emphasized 
portion of Claim 5. As such, the rejection is improper. 

Nonetheless, the Examiner mistakenly relies on Ferrat to remedy Brown's 
deficiency. The Examiner once again, asserts that Ferrat, paragraphs [0089]-[0091] 
teach ascertaining whether the identified record, in its current form as affected by the 
detected change, was pushed to the local application data store; and if not, 
synchronizing the remote application data store with the local application data store. 



The cited paragraphs are reproduced as follows: 



[0088] 3.3 Push and Pull Mechanism 

[0089] One of the requirements that we would like to satisfy is the 
ability to do both "push" and "pull" in a single UniSync engine. For 
example, the ability to do a "push" for a spoke to move all the changes 
to the hub server and eventually resolve conflicts, and then do a "pull" 
to synchronize the hub server and the spoke database. These 
operations "push" and "pull" may be optional. 

[0090] The "push" and "pull" can be applied for all the commands that 
are described previously. UniSync engine provides the 3 basic 
commands snapshot, pointUpdate and continuousUpdate. They can 
"push" or "pull" depending of the requirement. 

[0091] These commands can be called directly from UniSync API. 
UniSync engine will support both "push" commands and "pull" 
commands at the same time. The user/application will decide to "push" 
or to "pull" and snapshot table for example depending on which site the 
command is executed. The outcome should be exactly the same for 
the UniSync engine. 

Ferrat, paragraphs [0088]-[0091]. 

The cited passage discusses a synchronization environment with central hub 
server with several spoke clients. A spoke client can push changes to the hub 
server. The hub server resolves conflicts, if any. The spoke can then pull changes 
The conflicts resolved by the hub server relate to related changes received from 
other spoke clients. See, e.g., Ferrat, paragraph [0082]. Ferrat makes no mention 
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or suggestion that the hub server ascertains whether an record identified as having 
been changed, in its current form as affected by the detected change, was pushed to 
the hub server from a spoke client and, if not, local application data store from a 
remote application data store, and, if not, synchronizing the spoke client with the hub 
server. 

Consequently, the combination of Brown and Ferrat fail to teach or suggest a 
method that includes: 

a) ascertaining whether the identified record, in its current form as affected by 
the detected change, was pushed to the local application data store from a 
remote application data store; and 

b) if not, synchronizing the remote application data store with the local 
application data store. 

For at least these reasons, Claim 5 is felt to distinguish over Brown and 
Ferrat. Claims 6, 7, and 48 are thus also felt to distinguish over Brown and Ferrat 
based on their dependency from Claim 5. 

Claim 10 is directed to a coordinated push and user-initiated synchronization 
method and includes the following combination of elements. 

1 . detecting changes to a local application data store; 

2. identifying a first record in the local application data store affected by a 
detected change; 

3. pushing the first record to a remote application data store; 

4. ascertaining whether the pushed record, in its current form as affected 
by the detected change, has already been replicated in or deleted from 
the remote application data store and, if not, updating the remote 
application data store with the pushed record; 

5. detecting changes to the remote application data store; 
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6. identifying a second record in the remote application data store 
affected by a detected change; 

7. ascertaining whether the second record, in its current form as affected 
by the detected change, has already been pushed into the remote 
application data store in order to determine whether the remote 
application data store will be updated with the pushed record and, if 
not, synchronizing the remote application data store with the local 
application data store, otherwise ignoring the pushed record. 

As with Claim 1 , Brown and Ferrat fail to teach a method that includes 
"ascertaining whether the pushed record, in its current form as affected by the 
detected change, has already been replicated in or deleted from the remote 
application data store and, if not, updating the remote application data store with the 
pushed record" 

For at least these reasons, Claim 10 is felt to distinguish over Brown and 
Ferrat. Claims 11, 12, and 15 are thus also felt to distinguish over Brown and Ferrat 
based on their dependency from Claim 10. 

Claim 17 is directed to a computer readable medium having instructions for 
performing the method steps of Claim 1 . For the same reasons Claim 1 
distinguishes over Brown and Ferrat so does Claim 17. Claims 18-20 are thus also 
felt to distinguish over Brown and Ferrat based on their dependency from Claim 17. 

Claim 21 is directed to a computer readable medium having instructions for 
performing the method steps of Claim 5. For the same reasons Claim 5 
distinguishes over Brown and Ferrat so does Claim 21 . Claims 22 and 23 are thus 
also felt to distinguish over Brown and Ferrat based on their dependency from Claim 
21. 
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Claim 26 is directed to a computer readable medium having instructions for 
performing the method steps of Claim 1 0. For the same reasons Claim 1 0 
distinguishes over Brown and Ferrat so does Claim 26. Claims 27, 28, and 31 are 
thus also felt to distinguish over Brown and Ferrat based on their dependency from 
Claim 26. 



Conclusion: All pending claims are felt to be in condition for allowance. The 
foregoing is believed to be a complete response to the outstanding office action. 

Respectfully submitted, 
Richard Detweiler, et al 



By /Jack H. McKinnev/ 

Jack H. McKinney 
Reg. No. 45,685 



August 1, 2007 
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APPENDIX OF CLAIMS INVOLVED IN THE APPEAL 



1. (previously presented) A coordinated push synchronization method, 
comprising the acts of: 

detecting changes to a local application data store; 

identifying a record affected by a detected change; 

pushing the identified record to a remote application data store; 

ascertaining whether the pushed record, in its current form as affected by the 
detected change, has already been replicated or deleted in the remote application 
data store in order to determine whether the remote application data store will be 
updated with the pushed record; 

if not, updating the remote application data store with the pushed record and 
identifying the pushed record in the remote application data store as having been 
pushed from the local application data store to the remote application data store, 
otherwise ignoring the pushed record. 

2. (previously presented) The method of Claim 1 , wherein the act of 
ascertaining includes comparing a local change counter associated with the pushed 
record in the local application data store with a remote change counter associated 
with a corresponding record in the remote application data store. 

3. (original) The method of Claim 1 , wherein the act of pushing the identified 
record comprises: 

if the identified record has been detected as being new, pushing a replica of 
the identified record with instructions to save the replica in the remote application 
data store; 

if the identified record has been detected as being modified, pushing a replica 
of the identified record with instructions to save the replica in the remote application 
data store replacing a prior version of the record; and 
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if the identified record has been detected as being deleted, pushing 
instructions to delete a prior version of the identified contained in the remote 
application data store. 

4. (previously presented) The method of Claim 1 , wherein the act of 
identifying the pushed record in the remote application data store as a pushed record 
comprises associating an indicator with the pushed record identifying the pushed 
record in the remote application data store as a pushed record. 

5. (previously presented) A coordinated user-initiated synchronization method, 
comprising the acts of: 

detecting changes to a local application data store; 

identifying a record affected by a detected change; 

ascertaining whether the identified record, in its current form as affected by 
the detected change, was pushed to the local application data store from a remote 
application data store; and 

if not, synchronizing the remote application data store with the local 
application data store. 

6. (previously presented) The method of Claim 5, wherein the act of 
ascertaining includes examining an indicator associated with a pushed record 
identifying the pushed record in the remote application data store as a pushed 
record. 

7. (original) The method of Claim 5, wherein the act of synchronizing 
comprises: 

if the identified record has been detected as being new, replicating the 
identified record in the remote application data store; 
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if the identified record has been detected as being modified, replicating the 
identified record in the remote application data store replacing a prior version of the 
record; and 

if the identified record has been detected as being deleted, deleting the 
version of the identified record from the remote application data store. 

8. (cancelled) 

9. (cancelled) 

10. (previously presented) A coordinated push and user-initiated 
synchronization method, comprising: 

detecting changes to a local application data store; 

identifying a first record in the local application data store affected by a 
detected change; 

pushing the first record to a remote application data store; 

ascertaining whether the pushed record, in its current form as affected by the 
detected change, has already been replicated in or deleted from the remote 
application data store and, if not, updating the remote application data store with the 
pushed record; 

detecting changes to the remote application data store; 

identifying a second record in the remote application data store affected by a 
detected change; 

ascertaining whether the second record, in its current form as affected by the 
detected change, has already been pushed into the remote application data store in 
order to determine whether the remote application data store will be updated with the 
pushed record and, if not, synchronizing the remote application data store with the 
local application data store, otherwise ignoring the pushed record. 
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1 1 . (previously presented) The method of Claim 10, wherein the act of 
ascertaining whether the pushed record has been replicated in or deleted from the 
remote application data store includes comparing a local change counter associated 
with the pushed record in the local application data store with a remote change 
counter associated with a corresponding record in the remote application data store. 

12. (previously presented) The method of Claim 10, wherein the act of 
ascertaining whether the pushed record has been replicated in or deleted from the 
remote application data store includes examining an indicator associated with the 
pushed record identifying the pushed record in the remote application data store as a 
pushed record. 

13. (cancelled) 

14. (cancelled) 

15. (currently amended) The method of Claim 10, further comprising, after 
updating the remote application data store with the pushed record, identifying the 
pushed record in the remote application data store as having been pushed from the 
local application data store to the remote application data store. 

16. (cancelled) 

17. (previously presented) A coordinated push synchronization computer 
program product comprising a computer useable medium having computer readable 
instructions thereon for: 

detecting changes to a local application data store; 
identifying a record affected by a detected change; 
pushing the identified record to a remote application data store; 
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ascertaining whether the pushed record, in its current form as affected by the 
detected change, has already been replicated or deleted in the remote application 
data store in order to determine whether the remote application data store will be 
updated with the pushed record; 

if not, updating the remote application data store with the pushed record and 
identifying the pushed record in the remote application data store as having been 
pushed from the local application data store to the remote application data store, 
otherwise ignoring the pushed record. 

1 8. (previously presented) The product of Claim 1 7, wherein the instructions 
for ascertaining include instructions for comparing a local change counter associated 
with the pushed record in the local application data store with a remote change 
counter associated with a corresponding record in the remote application data store. 

1 9. (original) The product of Claim 1 7, wherein the instructions for pushing the 
identified record comprise instructions for: 

if the identified record has been detected as being new, pushing a replica of 
the identified record with instructions to save the replica in the remote application 
data store; 

if the identified record has been detected as being modified, pushing a replica 
of the identified record with instructions to save the replica in the remote application 
data store replacing a prior version of the record; and 

if the identified record has been detected as being deleted, pushing 
instructions to delete a prior version of the identified contained in the remote 
application data store. 

20. (previously presented) The product of Claim 17, wherein the instructions 
for identifying the pushed record in the remote application data store as a pushed 
record comprise instructions for associating an indicator with the pushed record 
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identifying the pushed record in the remote application data store as a pushed 
record. 

21 . (previously presented) A coordinated user-initiated synchronization 
computer program product comprising a computer useable medium having computer 
readable instructions thereon for: 

detecting changes to a local application data store; 

identifying a record affected by a detected change; 

ascertaining whether the identified record, in its current form as affected by 
the detected change, was pushed to the local application data store from a remote 
application data store; and 

if not, synchronizing the remote application data store with the local 
application data store. 

22. (previously presented) The product of Claim 21 , wherein the instructions 
for ascertaining include instructions for examining an indicator associated with a 
pushed record identifying the pushed record in the remote application data store as a 
pushed record. 

23. (original) The product of Claim 21 , wherein the instructions for 
synchronizing comprise instructions for: 

if the identified record has been detected as being new, replicating the 
identified record in the remote application data store; 

if the identified record has been detected as being modified, replicating the 
identified record in the remote application data store replacing a prior version of the 
record; and 

if the identified record has been detected as being deleted, deleting the 
version of the identified record from the remote application data store. 

24. (cancelled) 
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25. (cancelled). 



26. (previously presented) A coordinated push and user-initiated 
synchronization computer program product comprising a computer useable medium 
having computer readable instructions thereon for: 

detecting changes to a local application data store; 

identifying a first record in the local application data store affected by a 
detected change; 

pushing the first record to a remote application data store; 

ascertaining whether the pushed record, in its current form as affected by the 
detected change, has already been replicated in or deleted the remote application 
data store and, if not, updating the remote application data store with the pushed 
record; 

detecting changes to the remote application data store; 
identifying a second record in the remote application data store affected by a 
detected change; 

ascertaining whether the second record, in its current form as affected by the 
detected change, has already been pushed into the remote application data store in 
order to determine whether the remote application data store will be updated with the 
pushed record and, if not, synchronizing the remote application data store with the 
local application data store, otherwise ignoring the pushed record. 

27. (previously presented) The product of Claim 26, wherein the instructions 
for ascertaining whether the pushed record has been replicated in or deleted from 
the remote application data store include instructions for comparing a local change 
counter associated with the pushed record in the local application data store with a 
remote change counter associated with a corresponding record in the remote 
application data store. 
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28. (previously presented) The product of Claim 26, wherein the instructions 
for ascertaining whether the pushed record has been replicated in or deleted from 
the remote application data store include instructions for examining an indicator 
associated with the pushed record identifying the pushed record in the remote 
application data store as a pushed record. 

29. (cancelled) 

30. (cancelled) 

31 . (previously presented) The product of Claim 26, further comprising 
instructions for, after updating the remote application data store with the pushed 
record, identifying the pushed record in the remote application data store as having 
been pushed from the local application data store to the remote application data 
store. 

32. (cancelled) 

33. (cancelled) 

34. (cancelled) 

35. (cancelled) 

36. (cancelled) 

37. (cancelled) 

38. (cancelled) 
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39. (cancelled) 

40. (cancelled) 

41. (cancelled) 

42. (cancelled) 

43. (cancelled) 

44. (cancelled) 

45. (cancelled) 

46. (cancelled) 



47. (previously presented) The method of Claim 4, wherein the act of 
associating comprises setting a coordination flag for the pushed record. 

48. (previously presented) The method of Claim 6, wherein the indicator 
comprises a coordination flag, a set coordination flag indicating that a record is a 
pushed record and a reset coordination flag indicating that the record is not a pushed 
record. 
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Evidence Appendix 

There is no extrinsic evidence to be considered in this Appeal. 
Therefore, no evidence is presented in this Appendix. 
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Related Proceedings Appendix 

There are no related proceedings to be considered in this Appeal. Therefore, no 
such proceedings are identified in this Appendix. 
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